Static-Analysis Assisted Dynamic Verification of MPI Waitany Programs (Poster Abstract)

Overview: It is well known that the number of schedules (interleavings) of a concurrent program grows exponentially with the number of processes. Our previous work has demonstrated the advantages of an MPI-specific dynamic partial order reduction (DPOR, [5]) algorithm called POE in a tool called ISP [1,2,3] in dramatically reducing the number of interleavings during formal dynamic verification. Higher degrees of interleaving reduction were achieved when the programs were deterministic. In this work, we consider the problem of verifying MPI using MPI_Waitany (and related operations wait/test some/all). Such programs potentially have a higher degree of non-determinism. For such programs, POE can become ineffective, as shown momentarily. To solve this problem, we employ static analysis (supported by ROSE [4]) in a supporting role to POE to determine the extent to which the out parameters of MPI_Waitany can affect subsequent control flow statements. This informs ISP’s scheduler to exert even more intelligent backtrack/replay control. Illustration: Consider the MPI example shown in Figure 1(a). The MPI code for rank 0 (lines 1− 12) issues two MPI_Irecvs (lines 2− 3) and later invokes a MPI_Waitany (line 5) on the request handles returned by the MPI_Irecvs. The code in lines 6 − 10 will execute along code paths determined by the value of the done variable (recall that this variable represents the index into the request array returned by MPI_Waitany). For sound verification, ISP must ensure that a sufficient number of values of the done variable are returned. In this example, done = 0 and done = 1 are both feasible, since both the posted Irecv have matching sends available. Thus, the previous POE algorithm and the proposed one will both execute two interleavings, one for each value of done. Now consider the MPI program in Figure 1(b) – a slight modification of that in Figure 1(a). The MPI program issues two MPI_Waitanys in a for loop (lines 5−6). Our previous version of the POE algorithm would examine four interleavings (two interleavings for the first loop iteration, and two more interleavings under that for the second loop iteration). Under the new algorithm, this program would result in only two interleavings to accommodate the use of the received data. Since the done variable itself is not used, we will not need to create separate interleavings to account for possible control-flow changes based on it. Now, if